AN EXAI4INATI0N OF PROJECT MANAGEMENT 
Airo CONTROL REQUIREMENTS AND 
ALTERNATIVES AT PNOC 



Charlotte Ruth Gross 



NAVAL POSTGRADUATE SCHOOL 

Monterey, California 




THESIS 



AN EXAMINATION OF PROJECT MANAGEMENT 
AND CONTROL REQUIREMENTS AND 
ALTERNATIVES AT FNOC 

by 

Charlotte Ruth Gross 



June 1981 



Thesis Advisor: N. R. Lyons 



Approved for public release; distribution unlimited 



T2u00 



SCCUftiTY CL ASSiriC ATiON or THIS ^«GC Dm»m Entmrmd) 



REPORT DOCUMENTATION PAGE 


READ INSTRUCTIONS 
BEFORE COMPLETING FORM 


, MEFOMT NUMaCM 


i. GOVT ACCttllON NO. 


4. MfCiMlENT'S CATALOG NUMMCM 


4. title Su^tltla) 

An Examination of Project Management 
and Control Requirements and Alternatives 
at FNOC 


5. TYME OF MEPOMT k PEMIOO COVERED 

Master's Thesis; 

June 1981 


f. pcmformino org. report number 


7. AUTHO.fO 

Charlotte Ruth Gross 


4. contract or grant NUMBERr«) 


f. MEMFOMMiNO OMOANI Z ATION NAME AND AOOMffl 

Naval Postgraduate School 
Monterey, California 93940 


10. program ELEMENT. PRQj ECT. Ta$k 
AREA A WORK UNIT NUMBERS 


II COMTMOLLINO office M4mC 4mO AOO.CIS 

Naval Postgraduate School 
Monterey, California 93940 


IJ. HCPO.T OAT6 

June 1981 


11. mumiIen of fagcs 

85 


14. mONITOMInG agency name * AOONESSn# lr«m Cottirolllnk Office) 

Naval Postgraduate School 
Monterey, California 93940 


11. SECURITY CLASS, (el tblm rdperi) 

Unclassified 


1S«. OtCLASSI FI CATION/ down GRADING 
SCHEDULE 



l«. OlSTRlBUTlOf^ STATCMCNT (ol lfil« 



Approved for public release; distribution unlimited. 



17. OlSTMiauTlON ITATCMCMT (ol fA« «A«rf«cf ot^ioto^ Im Block 30, II dllfotcnt tomm Mopoti) 



It. SU^^LCMCnT AMY NOTES 



It. KEY WOflOI (Coftilmso r«r#r«« otOo II nmcoommer Ikoniltf ky kloek maiA«0 

Computer, information systems, project management, software 
package, MIS, user requirements, project control, project 
information system 



20. AASTMACT (Coftllmio tm rmwmoo cldc If oceoccorw Idmmlltr Or klock mmtko e ) 

The need for a project information and control system at 
FNOC was examined. Personal interviews and checklists were 
used to determine user requirements. Several manual and auto- 
mated alternatives were presented. The author concluded that 
the purchase of a software package, would in all probability, 
be the most efficient and effective alternative. Several packages 
were evaluated and 3 packages were finally presented for more 
____extensive_review_b^,^Ft^^ 

DO , 1473 EDITION OF t MOV It oatOLETS 
(Page 1) 0102-014- A« 0 l ’ 



tfCUWlTV CLAIIlFiCATlON OF TWIl FAOt Dole Bntorod) 



Approved for public release; distribution unlimited 



An Examination of Project Management 
and Control Requirements and 
Alternatives at FNOC 



by 



Charlotte Ruth Gross 
Lieutenant, United States Navy 
B.S., University of Minnesota, 1968 
M.S., University of Southern California, 1979 



Submitted in partial fulfillment of the 
requirements for the degree of 



MASTER OF SCIENCE IN INFORMATION SYSTEMS 

from the 

NAVAL POSTGRADUATE SCHOOL 
June 1981 



ABSTRACT 



The need for a project information and control system at 
FNOC was examined. Personal interviews and checklists were 
used to determine user requirements. Several manual and 
automated alternatives were presented. The author concluded 
that the purchase of a software package, would in all prob- 
ability, be the most efficient and effective alternative. 
Several packages were evaluated and 3 packages were finally 
presented for more extensive review by FNOC staff. 
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PREFACE 



Throughout this thesis the reader will find three cate- 
gories of statements. Scientific facts are those statements 
that are supported by scientific research in the field. 

These statements can be identified by a direct reference. 
Authors opinions are specifically identified as such. All 
other statements can be classified as General management 
lore* This type of statement refers to generally accepted 
theory in the management field; however it is unsupported by 
scientic research. 
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I. INTRODUCriON 



In an environment characterized by increased numbers of 
projects, drastic increases in demands for information, and 
strong limitations on personnel, computer, and financial 
resources. Fleet Numerical Oceanographic Central (FNOC) , 
must look at alternative courses of action to maintain an 
effective level of performance in project management. 

It is the intent of the author to examine the need and 
information requirements for, project information and con- 
trol system (PICS) at FNOC. This system should not only pro- 
vide for the flow of pertinent project information to top 
management; but also assist the project manager and other 
middle managers in estimating, assignment, and scheduling of 
project tasks and resources. Alternative courses of action 
will be identified and available software packages examined, 
to determine their capability of meeting those requirements. 

This document will provide to FNOC management assistance 
in selecting the appropriate course of action as well as 
providing a preliminary analysis of user requirements. 

Prior to examination of FNOCs project management needs, 
a review of the literature relevant to project management 
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will be provided. Specifically, there will be an examination 
of several of the problems associated with software project 
management. An awareness of these problems will assist the 
project manager in visualizing the importance of effective 
project control. 
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II. REVIEW OF PROBLEMS IN SOFTWARE PSOJECT MANAGEMENT 



An increasing percentage of DOD monies are allocated for 
direct software acquisition or embedded software. In 1977, 
the Onited States government estimated the cost of software 
development, testing, and maintenance to be about $4 billion 
per year. At that time the government owned approximately 
$25 billion worth of currently used software. [Ref. 1] 
Overruns of 100% in both cost and delivery time have not 
been uncommon occurrences in software projects; and in fact, 
there have been cases of total failure to develop systems. 

There has been a great deal of attention and speculation 
as to the cause of these problems. It is the author’s con- 
tention that effective project management on the part of the 
contracting project manager can minimize and perhaps elimi- 
nate most of these problem areas. 

A review of the literature surfaced several problem 
areas in software project management. These problems are 
presented here, together with information for the project 
manager who desires to minimize the risk of project failure. 
Certainly the awareness alone, of potential problems, 
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will increase the effectiveness of the project manager, and 
provide direction toward project success. 



I 

PROBLEM: 

Poor accountability and control structure, such as: 

* inappropriate measures of effectiveness 

* minimizing development costs and schedule 

* emphasis on percent coded 



The first method of control starts with the organiza- 
tional structure. Usually the project organization is set 
up to meet a specific objective and it dissolves after it 
has been accomplished. This, in itself can create a problem. 
The manager may not be fully aware of the skills of the pro- 
gramming teams. The host organization must therefore strive 
to maintain accurate documentation as to those abilities. 

Managers must also decide on a mangement system. There 
are many automated management control systems available to 
assist a project manager; however, it should be remembered 
that they must fit the organization, and that simply because 
they have been used with great success by others , does not 
guarantee their success in all structures or projects. This 
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is a point that nany managers fail to take into account when 
they are looking for that magic control method. In matching 
a method to the organization the manager must take into 
account such things as whether or not project management is 
linear or matrix oriented, what item the organization is 
most interested in tracking, and what levels of reporting 
are required. 

Establishment of a project control room to centralize 
information needed by the project team might prove to be of 
value to the organization. Some of these items include: 
documentation, master schedules, status reports, change 
authorizations, budget, systems flow charts, edit rules, and 
user training information. Consideration might also be 
given to the establishment of a project control secretary 
position. 

Emphasis on percent coded tends to get people coding too 
early and key activities such as requirements and design 
validation, test planning and draft of user documents are 
neglected. It is also true that percent coded is not indica- 
tive of where the project is relative to the schedule. It is 
extremely subjective. To combat this problem, key milestones 
should be set. These must be measurable milestones. For 
example, milestone 1 might be acceptance/approval of design 
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criteria by the user. Involvement of the user early in the 
project and throughout its existence will help to keep the 
project on track and hopefully surface user problems early 
in the project. 

Structured programming techniques; specifically top-down 
design, provides a procedure for organizing and developing 
the control structure of a program in a way which focuses 
attention early to the critical issues of integration and 
interface identification and definition, 

I 

PROBLEM; 

Software requirements specifications 

(if they exist) 

are often ambiguous. 

1 _j 

These requirements must be written by personnel knowled- 
gable in both the systems requirements and software develop- 
ment. This is often not the case, especially where embedded 
software is involved. 

Technology can be of assistance here. Machine analyzable 
software requirements systems are available. The pioneer in 
this technology was ISDOS, developed by Teichroew at the 
University of Michigan [Ref. 2]. although it was developed 
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primarily for business systems applications; the United 
States air Force is currently using and sponsoring exten- 
sions to ISDOS under the computer aided requirements analy- 
sis (CABA) program. Another even more extensive and powerful 
system is one developed under the software requirements 
engineering program (SBEP) by TRW for the United States Army 
Ballistic Missile Defense Advanced Technology Center. Even 
these automated systems have limitations however; the capa- 
bilities to represent large file processing and man-machine 
interactions are limited. They are a start however. 

Often a project manager will inherit a project which is 
not adequately defined. Realizing this and taking immediate 
steps to remedy the problem is necessary to project success. 
The extra time spent at this point will pay off in the end. 
Because of the nature of software development, errors 
detected early in the cycle are less costly then those dis- 
covered in later phases. Figure 1 [Ref. 3]. A project man- 
ager must avoid the temptation to allow detailed design and 
coding to begin prior to establishment of user requirementts 
and an overall plan. The extra time spent in the definition 
and design phase will be time well spent if it minimizes the 
likelihood of problems in later phases. 
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ERROR DETECTION AND DESIGN PHASE 
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PROBLEM: 

Software testing and reliability activities are 
often not considered until the code has been 
run for the first time and found not to work. 

1 

In general the cost of testing, 40%-50% of the devlop- 
ment effort, is due to the high cost of reworking the code 
at this late phase of the cycle [Ref. 4]. There is a great 
deal of wasted effort resulting from the lack of an advanced 
test plan to efficiently and effectively guide testing 
activities. 

The development people must consider the testability of 
their design and ensure that code can be exhaustively tested 
before the next higher level of code is added. Early loca- 
tion and correction of errors results in much more reliable 
programs. A solid test plan should provide for an indepen- 
dent validation team to be established at the beginning of 
the project. 

The consequences of undetected errors can range from 
minor to disastrous. A well known example of the latter was 
the Mariner 1 interplanetary probe. The absence of one bar 
over a letter in a computational equation resulted in a 
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unrecoverable problem/ left no alternative but to destruct 
the $18.5 million dollar rocket shortly after launch. [Ref. 5] 
Reliability can be improved by imposing standards on 
programming style for all code written, structured program- 
ming has a lot to contibute in this area. Structured pro- 
gramming involves dividing a complex program into 
progressively smaller modules, each of which has a well 
defined task. The most refined modules are small and logi- 
cally straight forward. They have limited control structures 
and one entry and exit point. The conciseness of the modules 
allows the programmer to use formal mathematics to prove the 
correctness of the code. 

I — — — — ■ ■ ■■ - 

PROBLEM: 

Cost estimates in software projects are often 
incomplete and grossly inaccurate. 



There is always the element of risk, especially on 
projects that push the state of the art. Estimating hardware 
costs has followed established methods, software on the 
other hand, is seldom handed to a software estimating group. 
In fact, software estimating seldom follows any scientific 
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procedures, with perhaps the exception of those 
organizations utilizing PERT/CPM*. 

The DOD is currently evaluating macro and micro techni- 
ques for estimating resources required for ADP projects. The 
macro technique provides an overall lump sum estimate of 
manpower and costing factors for the entire systems life 
cycle. The micro technique provides detailed manpower and 
costing for each phase of the life cycle [Ref. 6]. 

Studies by industry have concluded that there are no 
simple universal rules for costing software accurately and 
that to estimate it accurately it is neccesssary to under- 
stand the nature of the individual program [Ref. 7]. 

It would appear that, the problem with software cost 
estimates is that until we have more standardization of 
procedures in the software industry, the estimates will con- 
tinue to be grossly inaccurate due in part to the varying 
programming methods. 

One pitfall to avoid in worrying about software costs is 
that of concentrating too much on reducing software develop- 
ment costs. What really needs to be reduced is software life 
cycle costs. Instead, we too often find project managers 

’('For additional information on PERT/CPM see Cleland,D.L. 
and King.H.H.. systems Analysis And Project Management , 
McGraw-Hill: 1 968, chapter T5T 
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making a lot of trade-offs during the software development 
to meet schedule and cost constraints. Many of those trade- 
offs trade maintainability for speed of development. 

In a discussion during the 1973 Symposium on the High 
Cost of Software, it was pointed out that the avionics soft- 
ware in the Air Force cost something like $75 per instruc- 
tion to develop; however, the maintenance* of the software 
had costs up to $4000 per instruction [Ref. 8]. 

The trend projected through 1985 is for software costs 
to continue to rise [Ref. 9]. In part, this is due to an 
increase in size and complexity of projects and an overall 
increase in the rate of technological change. The industry 
is currently pouring R&D money into exploration of auto- 
mated methods. Some progress has been made in this area; 
however in the author’s opinion, it will be some time before 
wide spread use. 



PROBLEM; 

Schedule slippage 



♦Maintenance includes all costs after the initial devel- 
opment effort associated with keeping the software in opera- 
tion (including revisions/upgrades) . 
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Schedule slippage results for a number of reasons. Nota- 
ble among them is personnel related problems. Skill levels 
among programmers vary greatly, also the amount of time nec- 
cessary to program in different languages varies. These fac- 
tors together with the degree of complexity of the system 
required, must be considered by the project manager in mak- 
ing the schedule estimate. Most often a project manager 
inherits a project for which these estimates have been made 
prior to the assignment of the project team and the project 
manager will have to make adjustments and recommednations to 
deal with inappropriate estimates. 

Project managers must rid themselves of the idea that if 
they get behind schedule, adding more programming staff will 
solve their problem. Dn the contrary, in many instances it 
will no doubt have quite the opposite affect That is, the 
new staff will have to be brought up to speed and this 
entails pulling experienced programmers off the job for this 
purpose, resulting in even greater delays. Brooks' Law 
states: "Adding manpower to a late software project makes it 
later " [Ref. 10 ], 

It is obvious that the preceding problems are not inde- 
pendent, and that difficulty in any one of them has a signi- 
ficant impact on each of the others. 
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In summary, the difference between software project 
successes and failures has most often been traced to good or 
poor .practices in software management. These problems can 
be divided into the following three major areas: 

POOR PLAHMING: Generally this leads to large amounts of 

wasted effort and idle time because of tasks being unne- 
ceassarily performed, overdone, poorly synchronized, or 
poorly interfaced. 

POOR CONTROL: A plan is useless when it is not kept up to 

date and used to manage the project. Also, the selection 
of the correct control method for the organization is cri- 
tical for success. 

POOR HESOaECE ESTIMATION: Without a firm idea of how much 

time and effort a task should take, the manager is in a 
poor position to exercise control. Improper assignment of 
personnel to tasks can cause cost and schedule overruns. 

In short, the key to project success lies with the man- 
agement team and the efforts they make to establish project 
control. In the following chapters, the author will examine 
FNOC*s project management needs in relation to these and 
other considerations. 
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III. OVERVIEW OF FNOC OPERATIONS 



FNOC provides a wide spectrum of numerical , meterologi- 
cal, and oceanographic products to worldwide users on a 
real-time basis. A multi-mainframe computer center is used 
to execute report processing, analysis, prediction, display 
and research jobs as a major part of the command's mission. 

A standard sequence of scheduled jobs known as the opera- 
tional run (OPS BUN) is processed every 12 hours to accom- 
plish a complete global me terological and oceanographic 
analysis and prognosis cycle. A database of current environ- 
mental observations and a complete set of climatological 
information is used. The goal of the OPS RUN being to pro- 
vide analysis and forecast fields and data for transmission 
to DOD facilities and users as soon as possible after the 
receipt of raw observations. 

FNOC is an integral part of the naval oceanographic and 
materological support system. See Figure 2. Environmental, 
metero logical, oceanographic observations (raw data) and 
requests for services come into FNOC, the primary production 
facility, via the Automated Weather Network (AWN), AUTODIN, 
ANSAT, or the Suitland data line. The raw data is quality 
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checked, sorted, and edited by computer programs, after 
which the analysis, prognosis, and applications programs are 
run and the output processed and placed in the integrated 
database. 

A sophisticated series of prediction programs generate 
forecast variables such as wind, temperature, pressure, 
moisture, and sea heights, to provide the fleet with a four 
dimensional measure of the air-ocean environment in which 
they operate. These products are distributed to the four 
weather centrals (Pearl, Guam Norfolk, and Rota) via the 
Naval Environmental Data Network (NEON) and the Naval Envi- 
ronmental Display System (NEDS) . The weather centrals tailor 
these products before disseminating them to end users. In 
some cases FNOC provides environmental pro-ducts directly to 
the end users. 

The products produced by FNOC are of two basic types; 
routine/ scheduled or tailored. Special requests for tai- 
lored products are based on changing fleet or other opera- 
tional committments. These products are transmitted via the 
telecommunications system. Figure 3 is a listing of some of 
the products currently provided by FNOC. A primary emphasis 
in oceanographic modeling is support of antisubmarine war- 
fare forces. FNOC provides fleet units with expected 
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detection ranges for each of their acoustic sensor systems, 
ao matter where they are. Currently, satelite processing is 
becoming the focus of attention, as a means of providing a 
more accurate database. 

To provide all these services; FNOC maintains twenty- 
four hour computer center operations, manned by military 
and civilian personnel. There is considerable development of 
advanced techniques and capabilities in data processing, 
ocean and atmospheric analysis, prediction, display, appli- 
cations and communications. There is continual planning and 
implementation of computer systems upgrades. 

The project approach is frequently used to meet new and 
changing requirements at FNOC; hence, tijere is a sound rea- 
son for seeking to optimize the project management proce- 
dures and controls. 
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FNOC PRODUCTS 



SOOTIHB 

area forecasts 
wind and sea warnings 
terminal and local forecasts 
oceanographic outlooks 
acoustic predictions 

analysis and prognosis for atmosphere and ocean 
TAILORED 

optimum track ship routes <OTSR) 

enroute ship weather forecasts (WEAX) 

refractive effects 

ballistic wind and densities 

amphibious forecasts 

environmental briefings 

climatological studies 

optimum path aircraft routing (OPARS) 

acoustic predictions 

search and rescue (SAR) 

Figure 3 
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IV. NATURE OF THE PROBLEM 



A. PAST HANDLING OF PROJECTS 

In late 1976 FNOC adopted a computerized descriptive 
list of projects. This listing was originally developed for 
use exclusively by the Data Integration Department. This 
action constituted the first step in the development of a 
MIS to assist in project control. This list was only a 
beginning and fell far short of fullfilling the needs of the 
command. Due to other commitments and limited resources, 
little progress was made in improving the system. There 
were several serious problems with the system; the report 
format was not well defined, file updates were irregular and 
incomplete, and milestone dates were passed without comment 
or explanation. A serious problem worth discussing, was the 
fact that the system lacked middle management support. The 
primary reasons given for dissatisfaction with this MIS 
were that it was a cumbersome and ill-defined system and 
that it provided very little, if any, benefits to the middle 
ma nager. 

The MIS received considerable command attention between 
1976 and 1977; however, commitment of personnel resources to 
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solve its many problems was lacking. After this period the 
MIS received only ocasional command level emphasis and by 
mid 1979 there was considerably less insistence on keeping 
the information updated. By 1980 the commanding officer had 
taken the HIS out of operation completely. 

It would seem that, by all development standards, this 
MIS was doomed from the start. Installing an information 
system is a complex job. It involves an examination of the 
entire structure of the organization and the information 
flow, clearly, this was not done in this case. The need 
exists for more planning and some definite attention to the 
organizational problems. 

B. CURRENT HANDLING OF PROJECTS 

Currently there is no automated MIS, neither are there 
any well-defined procedures for project control and 
reporting . 

Several manual reporting/tracking mechanisms have been 
tried recently, including the completion of the form in 
Figure 4. These represent major milestones/tasks to be 
accomplished during the periods indicated. These tasks are 
listed by department, staff position, and major projects. 
Although only a crude mechanism; it does force involved per- 
sonnel to give some thought to their own priorities in 
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relation to the command's priorities. The problem is, all 
personnel involved do not contribute; therefore the informa- 
tion is not complete. 

A second mechanism currently in use is the Projects and 
Plans Summary, Figure 5, initiated during the spring of 
1981. The Plans and Programs Officer has identified 8 gen- 
eral project areas based on function; within these areas 
there may be many projects. This summary identifies primary 
resources involved and schedu-led events, activities, and 
milestones for the current fiscal year and beyond. It is 
strictly a manual effort and the initial summary took three 
days of concentrated effort to produce (this time does not 
include its planning time) . These dates are monitored using 
strictly manual methods which requires constant vigilance 
and attention to detail. It is highly likely that when the 
current Plans and Programs Officer leaves FNOC (in the fall 
of 1981) this summary will cease to exist. 

Reporting of development projects is handled via the 
Work Unit Package which is submitted twice a year and 
updated only for major changes. This report is produced on 
a word processor; however no data manipulation is done. 

This is due in part to references 24 and 25, which 



30 



specifically prohibit use of word processing equipment for 
data manipulation without prior approval. 

C. FNOC PROJECT ENVIRONMENT 

FNOC utilizes a matrix organization for project manage- 
ment. Figure 6 represents the general structure of this 
organization, while Figure 7 depicts FNOC's operational 
organization. Matrix management is based on the concept of 
pulling together technical and managerial talent into a team 
to operate without the limits of discipline or organiza- 
tional lines. Matrix relationships are far more complex 
than traditional functional relationships in which the rela- 
tionships are predominantly vertical with few, if any, 
cross-functional aspects. Each major group or department is 
primarily concerned with its own goals. The matrix organiza- 
tion changes these traditional patterns by creating new ver- 
tical, horizontal, and diagcrnal relationships among its 
members. Communication becomes far more critical in a 
matrix organization; thus, tight project control and 
reporting becomes increasingly crucial. 

The department head's goal orientation must also change 
due to the matrix organization, in that they must be con- 
cerned with project goals in addition to their functional 
goals. [Ref. 11 ] In a matrix organization, the functional 
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specialist is placed in the difficult situation of taking 
direction from two managers; therefore, if there are not 
well defined channels of authorit/, there is potential for 
considerable conflict. Irregardless of this, due to the 
nature of the project environment, matrix management appears 
to be the proper choice. The built-in conflict, if handled 
properly, tends to enhance initiative among the participants 
as they compete for the limited resources. 

Matrix management is indeed difficult; however, it faci- 
litates the coordination and integration of many project 
activities, and provides the flexibility required in a com- 
plex multifunction environment such as FNOC.* 

Two staff positions were established to aid in project 
planning and control. The Plans and Programs Officer, res- 
ponsible primarily for long range planning and budgeting, 
and the Development Coordinator, responsible for coordinat- 
ing R&D activities under work unit funding. 



♦For additional reading on matrix management consult 
reference 11. 
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V. METHODOLOGY 



This study focused on the identification of user 
requirements for PICS. 

A. IDENTIFICATION OF THE PROBLEM 

The initial concentration of this thesis was to formu- 
late and describe a problem statement for project manage- 
ment at FNOC. Further discussion then focused on the 
various causes that had combined to produce the problem. The 
discussion also presented details about the past and current 
project management procedures . Having made a largely sub- 
jective determination of the problem, the next step 
involved an analysis of the user's needs. 

B. ANALYSIS OF OSER'S NEEDS 

Twelve key FNOC personnel were selected on the basis of 
their senior management positions at FNOC or their expertise 
and longevity in the project management environment. Indivi- 
dual PERSONAL INTERVIEWS were conducted with each of the 
tweleve individuals. The question posed was; what informa- 
tion requirements and/or capabilities would you like to see 
in a project management and control system at FNOC (either 
automated or manual) . Individuals responses were not 
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revealed to other interviewees and the interviewer limited 



her input, so as not to impose her views on those being 
interviewed. 

Responses from interviews were consolidated in an uned- 
ited CHECKLIST form and distributed to all FNOC personnel 
directly involved in project management at some level. Those 
involved in the personal interviews were also asked to com- 
plete the checklist inorder to validate the information and 
assure that the interviewer's interpretation of their origi- 
nal responses was correct. 

C. ANALISIS OP REQUIREMENTS 

Check list responses were classified as to management 
level (CO/XO/ DEPT HEAD/PRINCIPAL INVESTIGATOR/PEO JECT 
MANAGER) and analized. Items that were not felt to be 
necessary were deleted and a comprehensive list of require- 
ments was identified as the minimum necessary for a Project 
Information and Control System (PICS) . 

D. REVIEW OF SOFTWARE PACKAGES 

The criteria to be satisfied by a project managment 
software package was outlined and a survey of available 
software packages was made. Each software package was 
compared to the established criteria to select the most 
appropriate package/packages. 
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This preliminary screening was based on the established 
general system requirements. The intention was to reduce the 
number of packages being considered to those that appeared 
most likeley to meet the needs of the organization. 

E. PRESENTATION OF ALTERNATIVES 

A variety of feasible alteratives were identified in an 
attempt to cover the entire spectrum of possibilities. 

Their advantages and disadvantages were examined and dis- 
cussed to give the executive a view of their relative value. 
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VI. REQUIREMENTS 



A. OBJECriVES OF THE PROJECT INFORMATION AND CONTROL SYSTEM 
The overriding objective of most organizations in imple- 
menting an automated information system, is to increase the 
overall effectiveness of the organization involved. In the 
private sector, this translates into increased profits. In 
the public sector, it is not as easily measured. 

In order to define more specific objectives for the 
automated system, the author conducted personnel interviews 
with FN03 personnel. These interviews, together with the 
author's personal experience, were then used to describe the 
following overall objectives for an automated project man- 
agement and control system. 

1. Must require minimal inputs to the system, that is, 
once the initial system has been established, it should be 
no more cumbersome to maintain then current record 
beeping. 

2. Must deliver information to the appropriate manager 
when it is needed, so that situations requiring immediate 
decisions can be controlled, and situations that are not 
pressing can be deffered, but not to the point of loss of 
control. 



40 




i 

i 



i 



3. Must provide for simultaneous horizontal and vertical 
dissemination of necessary information, so that top level 
management and every operating department, will be ade- 
quately informed. In particular, it is important that the 
vertical dissemination of information follow only the 
necessary path. Furthermore, information sent in a ver- 
tical direction should be directed only as low/high as 
required to make or retract a decision, 

4. Must reduce reams of information to meaningful facts 
for management to use in planning the future operations of 
the organization. 

3. OSER INFORMATION REQOIREMENTS 

One of the first steps in developing or obtaining a 
software system, is to define the user’s requirements. This 
is far more involved than it sounds. After almost twenty 
years of attention, it is still often the case, that compu- 
ter based application systems are developed behind schedule, 
over cost, don*"t do as much as premised, and don't satisfy 
the user needs. At the heart of this problem, is the fact 
that, often the requirements for these applications were 
never stated accurately or completely in the first place. 

The fact that one may never reach perfection in this area 
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should not prevent an all out effort to identify require- 
ments as completely as possible. 

The importance to project success of getting these 
requirements right, can not be over stated. If the require- 
ments are not complete or correct, the system may not be 
usable. If the system is salvagable, the cost incurred in 
correcting the system may be excessive and the additional 
time required, could be time better spent elsewhere. There 
is also the possibility that the organizational effective- 
ness will be decreased, due to either not having a workable 
system, or having one that only partially meets their needs. 

Certainly our record of customer satisfaction is not 
good. For that reason, we must be aware of the problems and 
recognize that a substantial number of errors will exist in 
most requirements statements, unless specific action is 
taken to identify and remove them [Ref. 12]. 

There are three basic approaches to information require- 
ments analysis [Ref. 13]. 

DIRECT &RJ 1 LYSIS, which involves interaction with the user 
to identify decision processes and information elements. 
INDIRECT ANALYSIS is the evaluation of data utilization, 
such as observing people or reports, in order to infer 
information requirements. 
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HYBRID ANALYSIS, which is a combination of direct and 
indirect. 

The author utilized the hybrid analysis approach, 
together with her personal experience. It must be emphasized 
however; that this is simply a preliminary analysis of user 
requirements, and that a more extensive analysis should be 
undertaken if the decision is made to pursue this idea 
further. 

Information for data items was collected from inter- 
views, check list responses, and the author's experience. It 
was not felt necessary to include every data item from each 
source of inforohation. The amount of effort needed to obtain 
and enter some items of data, coupled with the increased 
storage, capacity necessary, and subsequent longer retrieval 
times, far overshadowed the possible benefit that could be 
gained from having that information on line. 

The author's value judgements were used to define a com- 
prehensive requirements list that would be useful without 
being overly demanding on resources. Future evaluations of 
update and usage rates of these data items should be made 
once a system is in use, to reduce the size of the database 
by eliminating unused items. 
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The following are deemed minimal information 
requirements for an automated project management and control 
system. 

♦ A means of establishing and tracking milestones, actual 
versus planned. 

♦ A method to provide information on available resources, 
personnel- monetary, and computer, and their utilization 
and/or allocation. 

♦ A means of indicating priority of projects. 

♦ A means of establishing and promulgating lines of 
authority and responsibility. 

♦ The ability to include narrative comments. 

♦ A means of indicating time/scheduling information. 

♦ A means to break the prpject up into tasks and subtasks 
for tracking and reporting. 

Reference 14 and appendix A , contain more detailed 
requirements for recommended data elements. 

It is recognized that these requirements differ with 
each level of management as does the degree of detail of the 
information. Anthony, [Ref. 15] in his framework for plan- 
ning and control, focuses on three categories of decisions 
which can be translated to the levels of project management 
at FNOC. They are: 

STRATEGIC PLANNING; which is equivalent to the type of 

decisions made at the staff level (CO, XO, staff 

♦CRAS (Computer Resources Accounting System) will pro- 
vide information related to EDP usage. 
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assistants) . They require only summary level information 
rather than more detailed reports. 

MAHAGEBIAL CONTROL: the key concern here is that 

resources are obtained and used effectively and effi- 
ciently to accomplish the defined objectives. In FNOCs 
project environment this can be equated to the principal 
investigator and department head. They require details of 
resource utilization and milestone information. 

OPERATIONAL CONTROL: at this level of decision the empha- 

sis is on assuring that tasks are carried out effectively 
and efficiently. This equates to the project manager 
level at FNOC. The project manager is concerned with the 
day to day operations. 

In order to provide the flexibility necessary to meet 
the diverse needs of the various users, this information 
should be accessable according to a number of retrieval 
criteria, such as: 

* miletones exceeded 

* upcomming milestones 

* funding source 

* responsible principle investigator , department, division 

* name of project manager 

* system relationship (ie. PEPSU, CCS, NEDS) 

* priority 

* estimated cost 

* duration of projects 
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* classification of projects (ie. development, operational, 
or maintenance) 

* resource allocation exceeded 

* noncompliance with established update schedule. 



C. GENERAL SYSTEMS CAPABILITIES 

Aside from the information requirements listed in the 
previous section, there are a number of desirable capabili- 
ties the system should have. They include the following, 
which are listed arccording to relative- importance: 



♦ The ability to run on equipment currently available to 
FNOC. 

♦ Easy/fast update procedures, requiring little or no 
additional effort on the part of project staff. 

♦ At least 3 levels of reporting; summary^ detailed and 
exception. To assure that only that inrormation of 
interest to a particular management level may be pre- 
sented. Aclcoff, [Ref. 16] emphasizes that contrary to 
popular belief, managers suffer most from information 
overload rather than lack of information. 

♦ A means to control who is authorized to update/modify 
project information in the file. 

♦ Backup/recovery procedures 

♦ Flexibility in report formats to allow individual manag- 
ers to get the information they require in a form that 
is most usefull to them. It is critical that middle 

. managers receive some direct tangible benefit from the 
project management and control system if they are to 
support it. 

♦ Specific definitions (ie. pro ject , task, sub- 
task, milests.ione) so that all reporting is done in 
regards to a common basis. 

♦ Interactive capability option 

♦ ability to support multiple users in the interactive 
mode. 
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VII. SOFTWARE PACKAGE REYIBW 



Commercially available software packages are becoming a 
major market factor in the data processing industry. They 
have many advantages over independently developed applica- 
tions. Most packages are well designed and documented and if 
the package has been on the market for some time, there is a 
good chance that most of the serious bugs have been elimi- 
nated, software packages permit the installation of a new 
system for relatively less cost than that of in-house devel- 
opment due to the fact that the cost can be spread over many 
customers. There is little or no risk of cast or schedule 
overrun usually associated with software development 
efforts. This allows management to establish dependable 
schedules for implementation and accurate budget plans. 

The purchase of a software package also allows the 
organization to utilize the professional talents of their 
programmers and systems analysts in the development of sys- 
tems unique to their organization, rather than in redevelop- 
ing systems that have been developed by many before them. 
Additionally, if an organization deals with a reliable ven- 
dor, they minimize the risk associated with maintaining the 
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system. The organization's options are broadened in that if 
they do not have the skills or personnel available to main- 
tain the system, they may call upon the assistance of the 
vendor {at the established rate) . 

There are a great number of software packages available 
that are marketed as aids to project management and control. 
These packages vary greatly in their scope. Some are 
designed to assist in the planning and tracking of only one 
project, others will handle any number of projects and pro- 
vide a great deal of flexibility within the organization. 

The problem is that there are very few written in FORTRAI), 
the preferred language for implementation at FNOC. 

The author found 3 packages that were available in 
FORTRAN. All 3 were eliminated from consideration because it 
was felt that they would not meet the minimum requirements. 
PAC I is marketed by International Sysytems Inc. (ISI), 
King of Prussia, Pa. This package is designed to track 
only 1 projeqt at a time and therefore was eliminated. 

P,D. P.-E.D.M. S. is available from Control Data Corpora- 
tion. This package was eliminated due to its strictly 
financial orientation. 

OSCAR, marketed by On-Line Systems, Pittsburgh, PA. , is 
available only in the time sharing mode. 
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Failing to find a suitable FORTRAN software package, the 
author chose to continue the search under the assumption 
that it was still feasible to purchase a software package 
and lease a COBOL compiler for less cost than in-house 
development. This idea will be discussed further in chapter 8. 

An examination of the trends and the state of the art in 
computer programming and software package applications, 
along with a preliminary analysis of the information 
requirements of a project information and control system 
(PICS) at FNOC, provided a background for establishing the 
criteria for selecting a computer software package. Woo- 
dridge, [Ref. 17] suggested 4 categories for software selec- 
tion criteria. These criteria address requirements in the 
area of features, technical and operational environment, 
implementation, and price of the package. The author used 
these 4 categories in the evaluation of the available 
packages. 

A. EVALUATION CRITERIA USED 
1 . Features 

The package should contain as many of the features 
described in chapter 6 , section B as possible. 
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2. Technical And Operational 



It must be possible to operate the package in the 
present environment. A thorough analysis of the technical 
and operational features of the candidate packages as they 
relate to the intended environment will assist in an appro- 
priate package selection. 

a. Hardware Configuration 

The package must be capable of operating on the 
equipment currently available. This includes the available 
core memory as well as peripheral equipment (ie. card 
reader, plotter, printer, etc.) Mainframes currently at 
FNOC available include 3 CDC 6500s, a CYBER 175, a CYBER 
203, a CYBER 170/720, and 2 PDF 11s. 

b. Higher Level Language 

A higher level language such as FORTRAN or COBOL 
must have been used to write the programs. 

c. Operating system 

The package should be capable of operating under 
the NOS/BE operating system. 

d. Ease Of Use 

The package must require minimal manual inputs. 
In other words; it should be no more cumbersome than current 
manual reporting , record keeping, and control mechanisms at 
FNOC. 
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e. Flexibility 

incorporate selected current procedures and 
reporting formats. 

3* Impl eme ntat io n And 3a it en a nee 

Two necessary requirements which ensure that the 
package can be implemented when needed and maintained with 
minimal effort are; 

a. Immediate Availability 

package must be available for immediate delivery 
and implementation, not in an under development status. 

b. Supplier’s Reputation And Business Integrity 

The supplier must be responsive to it user’s 

problems. They must be a well established company with a 
stable professional staff. 

c. Training And Documentation 

Documentation should cover the system, opera- 
tions, users, data preparation, and programming. It should 
allow for ease of use and maintenance. Training should be 
availablae and a training manual available for inspection. 

4 . ^rice 

Ideally, the package should be available to the 
user with no additional start-up costs. 

Software directories and professional publications were 
searched to identify feasible candidate packages. 
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Many were eliminatad immediately because they were not capa- 
ble of running on CDC equipment. The following packages 
were thought to possess most of the desired capabilities and 
warrant closer review and examination by FNOC professionals. 

B. INTERNATIONAL SYSTEMS* PAG II [Ref. 18] 

1 . General Information 

International systems Inc. (ISI ) , King of Prussia, 
PA, has developed a sotware package for project management 
called PAG II. ISI specializes in automated project manage- 
ment systems. Pac II performs numerous and varied functions 
as depicted in Figure 8. 

Pac II is a totally data base oriented system, con- 
sisting of 2 main modules. The planning module uses a sin- 
gle, easy to use input sheet. This module assists the user 
in directing and scheduling project resources. It supports 
a simulator capability with critical path ident ificiation, 
resource loading, and inter-project dependencies. Activi- 
ties can be assigned to resources by skill, as well as by 
specific resource identification. In fact, PAG II is capable 
of making proficiency level distinctions. 

The management module accumulates project progress 
information and makes available multi-level status, cost, 
and history information. A single turnaround document, 
which is designed by the user, feeds in the only information 
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PAC II PUNCTIONS 




^budget ing 


♦resource tracking 




♦planning 


♦Progress reporting 




♦project simulation 


♦automatic audit trail 




♦critical path analysis 


♦status accounting 




♦scheduling 


♦project monitoring 




♦modelling 


♦cost accounting 




♦skill scheduling 


♦statistical analysis 




♦on line/real time 


♦graphics 
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necessary to report progress. The outstanding feature of 
this module is its ability to alert management early when 
problems occur. The user sets tolerance levels and the 
updated data base is constantly monitored. Should any of 
these limitations be broken, PAC II automatically alerts 
management and produces detailed reports for analysis and 
corrective action, (ie. projects more than x months late or 
cost overruns greater than x percent) This is a particularly 
desirable feature. Project managers are understandably very 
reluctant to admit their project is behind schedule. This 
automatic reporting facility alerts upper management of this 
type of problem. 
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Although not explicitly termed milestones, the same 
function can be performed by defining what the PAC II sys- 
tem refers to as "EVENTS”. The PAC II system can be used 
to plan a single project or any combination of projects. Any 
number of activities or tasks with dependencies across pro- 
ject lines. 

PAC II offers a variety of input methods: computer 
generated turnaround document, manual input forms, punched 
cards, terminal entry, or OCR. Table entries are used for 
those items of information that are placed on the file once 
only; but are used constantly (ie. skill codes, holiday 
schedule) . Use of table entries can save the user many 
repetitive entries and provides for ease of maintenance and 
modification . 

ISI offers a separate add on option, the PAC II 
Report Writer, a facility for accessing the data base and 
producing reports that have not already been programmed into 
the system. This facility allows the user to request 
reports in a format they specify. Inputs are made via sim- 
ple English language statements. ISI also offers an inter- 
active package which provides a terminal data entry and 
planning capability and a graphics package which offers 
users 2 different options; plotter or printer. These 
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optional software packages as well as the Report Writer 
option, may be purchased with the basic PAC II system or be 
added on at a later date if desired. 

2, Cost Information 

Prices in effect as of the writing of this thesis 
are as follows: 



boy 

PAC II basic system $26,000 

plus 1 time installation 

total $26,000 



lease/purchase 
$15,600/yr 
$2, 160 
$17,760 



cost to purchase after 
one year^ 



$13,568 



optional software available 

PAC REPORT WRITER $4,000 $2,400/yr 

plus 1 time charge $ 330 

total (1 year) $2,730 

PAC INTERACTIVE $10,000 $ 6,000/yr 

plus 1 time charge $ Q30 

total (1 year) $6,830 



*70% of the first years lease payment and installation 
charge will be applied to reduce the purchase price. 
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Basic package price includes: 



PAC II COBOL source programs (on tape) 

PAC II maintenance and enhancements for 1 year 

pre installation meeting 

documentation 

* implementation guide (2) 

* coordinators case study (1) 

* users reference manual ( 2 ) 

* project leaders guide (2) 

* input forms 

. * user reference cards (25) 

* selection of turnaround documents 

installation, checkout, classes and OJT. 



3. Additional Information 



PAC II is currently installed on CDC equipment in 
several areas. Contact was made with MS. Dee Thorne in the 
data processing department of Reynolds Electric and Engi- 
neering, Las Vegas, Nevada [Hef. 19]. This company was cho- 
sen because it not only has a PAC II package installed on 
CDC equipment; but it is also operating under the NOS/BE 
operating system. This organization has a CDC 6400 and a 
CYBER 74 operating in tandem. Reynolds is the prime con- 
tractor for the Nevada Test Site and as such, they utilize 
PAC II in a variety of applications, including R&D develop- 
ment. 



Ms. Thorne indicated that they have received excel- 
lent response from ISI and that they are please with PAC II. 
They also purchased the PAC II REPORT WRITER option; but 
chose to develope their own interactive capability in-house. 
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Ms. Thorne is very agreeable to further consultation with 
FNOC staff. 

C. NICHOLS' H5500 [Ref. 20] 

1 . General Information 

In 1977 Nichols and company of Los Angeles, CA. , 
developed a project planning and control system, currently 
marketed as N5500. PERT and precedence networking enable 
the Nichols system to constantly monitor the impact of slip- 
pages and plan changes on in-process projects. What-if 
simulation capabilities highlight the impact that proposed 
projects and/or changes will have on the current in-process 
work load. Critical path analysis and slack time indica- 
tions provide the user the ability to optimize schedules 
and minimize resource waste. 

The planning process starts with the user's defini- 
tion of the organization's planning environment. This is 
accomplished through the use of a dictionary mechanism. 

This means this information need only be inputed once, the 
dictionary is maintained separately from the rest of the 
data which makes validation and modification a less compli- 
cated task. The use of the dictionary also allows the sys- 
tem to be adapted to any life cycle methodology, work 
breakdown structure, or documentation standards. The use of 
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the dictionary mechanism also significantly reduces the 
redundant entry of data. This means a time and effort 
savings to the user. 

The Nichols system, like the PAC II system, has an 
option for automatic assignment of resources by the system, 
which can be valuable to the planner. Changes to projects 
can be' accomplished with remarkable ease. Tasks may be 
added, changed, or deleted at any time, and the impact of 
any change will automatically be shown on all related tasks 
and projects. Task changes only require that a project num- 
ber, task number, and the revised data be entered. 

Project control is accomplished through the distri- 
bution of work schedule reports use to publish work assign- 
ments. Each person or group then reports back the work done 
on each task during the week, the work remaining to be done 
on each in-process task for that week, and any comments they 
wish to call to the project managers attention. 

The Nichols system has a mechanism where-by an overt error 
in a data field will not cause the system to stop perform- 
ing. The system simply makes a best guess and executes the 
program regardless of the number or severity of these 
errors. Although these errors are flagged and continue to 
be flagged until corrected; this feature should be closely 
examined by FNOC analysts to determine if it is desirable. 
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rhe Nichols system offers 20 report formats as part 
of its basic system. These reports cover 6 major groupings: 
administration, project planning and control, resource load 
and distribution, history and committment of resources, per- 
formance analysis, and accounting. One output file inter- 
faces with a plotter to provide critical path analysis. 

Other reports are in either tabular pr graphical form and 
are easily read and interpreted. The Nichols system also 
offers an optional generalized REPORT WRITER add on to allow 
the user to design their own reports. 

The weakness in the Nichols reporting structure lies 
in the fact that they measure progress via percent completed 
rather than milestones completed which can be very mislead- 
ing. The variance indicators are a key attraction, drawing 
managements attention to areas that are off target. 

2 . Cost Information 

Prices in effect as of the writing of this thesis 



are as follows: 


BOY 


Lease/Purchase 


N5500 Basic System 


$25,000 


$15,000/yr 


plu? 1 years maintenance 


n/a 


$ 1,000/yr 


total (1 year) 




$16, 000 


Cost to purchase after 
1 year 


n/a 


$11,500 


OPTIONAL SOFTWARE AVAILABLE 


(not available as 


lease) 


REPORT WRITER 


$ 5,000 




Interactive 


$10,000 
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Package price includes: 

object code (source will be delivered on tape upon receipt of 
payment) ^ t- r 

technical documentation (1) 

user manuals (5) 

5 days of on site training 

input forms 

1 year maintenance with purchase 
3. Additional Information 

rCektronics, a production facility that among other 
things produces terminals. N5500 was originally installed 
on a CYBER 73; but due to work load constraints, they 
switched to their CYBER 175. This action resulted in faster 
turnaround time. The operating system being utilized is NOS 
level 509. 

Contact was made with Ms. Charlene Madiman, who is 
the data base administrator for the Product Safety Division. 

[Ref. 21] She is responsible for data entry and interpreta- 
tion in support of the N5500 applications. Ms. Madiman 
indicated that they were very pleased with the N5500 pack- 
age. Their input is done via terminal and then batched into 
the system for processing. All data entry and interpreta- 
tion is done by Ms. Madiman and she says this is a full time 
job considering the number of projects/instruments she works 
with (over 350) . Inputs from project managers is very 
straight forward and involves entries on a pre-printed form. 
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Only two negative aspects were reported. First, that the 
previous version of the user manual was difficult to inter- 
pret.* The second problem area was in the error handling 
mechanism. Errors are flagged and continue to be flagged 
until corrected; however there is no indication as to the 
type of error. Error correction may prove to be very time 
consuming if the error is not readily apparent. 

Ms. Madiman indicated that their staff would be 
happy to discuss the package and its implementation further 
with FNOE staff.** Ms. Cindy Wong, marketing representative 
for Nichols, has indicated that there is a good chance that 
N5500 will be converted to NOS/BE for another customer in 
the near future [Ref. 22]. 

D. MSP»S PROJECTMANAGER [Ref. 23] 

1 . General Information 

PROJECTMANAGBR was marketed originally in 1972 under 
the name PHACS. It is a batch processing system which main- 
tains 3 major files: the resource file, the activity file, 

and the project files. Generally, the resource file and the 
activity file need only be set up once. The project file 

♦Nichols has released a new version of the user manual; 
however Ms. Madiman has not used it long enough to evaluate 
it . 

♦♦Contact point is Imants Goltz, manager of software 
support, at (503) 627-4675. 
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activity file need only be set up once. The project file 
contains the project plan, estimates, progress to date, and 
new projects as required. Projects can be broken down into 
subproject levels called tasks. 

PEOJECTMANAGER requires periodic updating of work 
accomplished and costs incurred. The user selects the 
reporting period. Mandatory entries are resource, project, 
and activity codes. Optional entries include task, rate of 
pay, computer use codes as well as various expence catego- 
ries and projection data items. 

Input can be by card, or card image on magnetic 
media, paper tape, or on-line data entry. All input tran- 
sactions are read into the system by a data validation pro- 
gram, which carries out exhaustive validation of each input 
record and rejects any erroneous data. A report is produced 
by the program so that all detected errors are clearly 
described to the user for correction and resubmission. 

PEOJECTMANAGER output consists Of 3 main types: 
validation reports, file content listings, and user selected 
progress reports. 

Validation reports are produced whenever data is entered. 
All input information is printed including error codes and 
pointers that identify incorrect items. 
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File coatent listings are obtained on demand in standard 
format and are of particular interest to those who control 
code allocation and related tasks. 

Progress reports can customize the system to the needs of 
the organization. Ihe number and type of the output 
reports is determined by the user. 

2. Cost Information 

The PROJECTMAN AGEE package can be purchased for 
$8,000, The package includes; 

Object code (on tape) 

1 days on-site training and advise 
1 set of documentation 

3, Additional Information 

Because of the relatively low cost, this package was 
included for consideration, even though it has not been 
implemented on CDC equipment and will require some in-house 
effort. The package was written in COBOL for IBM equiment; 
but has been coverted to operate on Burroughs, Honeywell, 
and ICL eguipement. A recent conversion from IBM to ICL 
DME/V took one user group 17 days, Larry Hagg, West Coast 
Region Manager fo MSP, has indicated that FNOC could obtain 
the source program at no additional charge, if they wished 
to convert the package themselves. [Ref. 24] The code should 
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be examined closely by FNOC analysts to determine if there 
would be any problem in conversion. Generally speaking, 
conversion of COBOL programs is relatively easy. The prob- 
lem is that once FMOC makes this conversion, asP will not be 
able to provide the maintenance. 

E. OTHER PACKAGES EXAHINED 

Other packages examined and subsequently eliminated are 
included here to assist FNOC in acquisition in the event 
that they choose to follow through on a PICS. QUICK TEOL, 
marketed by Quality Data Products Inc., is written in 
assembly language and can not be adapted to CDC equipment. 
PROJECT aONITOR, Marketed by Program Products Inc, was 
unresponsive to requests for additional information. Infor- 
mation on PC 70, marketed by Atlantic Software Inc., was 
received to late to include in this analysis. It is recom- 
mended; however that should FNOC consider the purchase of a 
software package, Atlantic Software Inc. Be given an invita- 
tion for bid. 
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VIII. ALTERNATIVE COURSES OF ACTION 



A. MANUAL ALTERNATIVES 

The alternatives requiring the least time, effort, and 
resources are those that require little change to current 
methods; however these alternatives may not be the most 
desirable. Two manual alternatives are presented here 
because they are considered viable alternatives. 

ALTERHATIVB 1: COMIINUB AS IS 

The obvious advantage to this alternative is that it 
requires no effort and no cost. That is, no direct cost. 

It could cost in terms of the efficiency and effectiveness 
of the organization. With the exception of the work unit 
reporting, which is done twice a year, there is no formally 
defined reporting structure for project management at FNOC. 
Formal reporting permits ready comparison of progress with 
plans and ensures a uniformity and consistency of informa- 
tion throughout the project. It also provides a historical 
record of tfue project. Failure to keep adequate well struc- 
tured reports makes it very difficult when others are forced 
to assume management duties, personnel turnover at FNOC is 
high due to the military environment. It- is therefore 
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critical that records allow the new project manager to trace 
what has been done and what remains to be done in the pro- 
ject. Many projects span several years, so the chance of 
turnover in project personnel is high. Use of civilians in 
key positions eases this problem somewhat; but does not eli- 
minate it all together. 

With no complete historical records of projects, FNOC 
will find great difficulty in presenting and defending their 
actions in case of contract dispute and litigation. Histor- 
ical records of a project can also assist the project man- 
ager in planning future projects and hopefully, in avoiding 
mistakes made in prior projects. 

&LTEBI1TIVB 2: EMHAMCBD HANOAL SYSTEM 

Enhancement of the current manual system could serve to 
alleviate some of the problems noted previosly. This 
enhancement can take the form of in-house establishment of 
definitions and procedures or perhaps the purchase of a pro- 
ject management methodology. 

In-house enhancement means those who establish the meth- 
odology will be intimately familar with the FNOC environ- 
ment; however they may not have the project management 
expertise that might be available on the outside. Staff 
time will still be required to determine amd put into effect 
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the methodology. This may be time that could be better 
spent elsewhere. 

There are several methodologies marketed that would pro- 
vide assistance in establishment of a project management and 
control system. Spectrum, marketed by Spectrum Interna- 
tional Inc. of Los ingeles,CA., and SDM/70, marketed by 
Atlantic Software Inc. of Philadelphia, PA., are two such 
methodologies. Spectrums price ranges from $32,000. Price 
is dependent on the number of programmers and analysts that 
must be trained. For a staff of 40-50, the price goes up to 
$50,000 , which includes the 16 days of training. The 
SDM/70 price of $30,000 includes training and the availabil- 
ity of a 24 hour hot line. These prices are relatively high 
in comparison to the automated packages available. They 
also fail to eliminate a key problem, relating to timeliness 
and accuracy of reports. The amount of correlation and 
calculations needed to produce some reports preclude the use 
of manual methods. Speed and accuracy are vital parts of 
progress reporting and are primary benefits accorded by a 
CO mputer. 

B. AUTOHATED ALTEBMATIVES 

Projects involve the deployment of a number of person- 
nel, eguipment, and money, and the integration of activities 
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to achieve some predetermined aim. This means that these 
activities must have been pre-planned, and the degree of 
success achieved depends to a large extent on the effective- 
ness of the planning. There are many types of projects and 
activities that do not lend themselves to manual control 
methods, for example, those that involve a large number of 
organizations or people. Additionally, the interdependen- 
cies of the various parts of the plan may be to complex for 
an individual to monitor and traditional methods of repre- 
sentation (ie. bar charts or schedules) may not represent 
the plan effectively. Finally, the project may span long 
lengths of time, making it difficult to track manually. 

With these points in mind, it becomes necessary to consider 
alternatives that provide for some means of automated assis- 
tance for PICS. The following alternatives provide that ^ 
capability. 

ALTEBHATIVE 3; IN-HOOSE DEVELOPMENT 

There are several advantages to in-house development. 
First, the system must be acceptable within the user envi- 
ronment and to the user group. By developing it in-house 
there is a greater opportunity for user involvement. The 
user must identify the new system with their operational 
requirements from the start, this too is made more viable by 
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in—house development. Change needs to be self— motiviat ed if 
it is to be successful and long lasting. The organization 
must take the responsibility for and be committed to the new 
program. 

In-house system development is rarely cost-effective 
when compared with outside purchase. Valuable system usage 
time is lost while the in-house system is developed. Due to 
the developmental nature, there is a degree of uncertainty 
as to the cost and schedule completion. Additionally, staff 
must be allocated to the development, who may be utilized 
more effectively on organization specific development (ie. 
oceanographic and/or meterological products) . The mainte- 
nance/enhancement cost of in-house software is normally in 
the region of 50% of the original cost per year. While it 
is true that in-house systems may be geared more closely to 
the original requirements; this may make them less flexible 
when ammendments become necessary. 

ALTERNATIVE 4; PORCHASB SOFTWARE PACKAGE 

It would be advantageous to puchase a software package 
rather than suffer the expense and time delay that would be 
necessary to design and program a PICS specifically for FNOC 
applications. Because the vendor is able to spread his 
package development costs across a number of installations; 
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it represents a real discount on the investment required for 
a similar development in-house. Funds can be budgeted and 
an installation date scheduled with a great deal more cer- 
tainty. The organization also gains the value of the ven- 
dors project management expertise and the experience gained 
by installations at other sites. Additionally, many of the 
software bugs will have been corrected. The problem is that 
the organization may not be as receptive to a package that 
will change their methods. It will be important to make the 
transition as painless as possible. Many of the packages 
allow the user to define terms and establish procedures con- 
sistent with those currently in use. The organization must 
assure that documentation is complete since they may be 
required to maintain it or puchase maintenance services from 
the vendor at additional costs. 

Purchase of a software package will probably require 
purchase/lease of a COBOL compiler since very few packages 
are written in FOHTSAN . Contact was made with Mr. Ken Gat- 
liffe, local CDC representative, concerning pricing informa- 
tion, A COBOL compiler for a CYBEB 170, 175 or CDC 6600 
would cost $12,540 to purchase or may be leased for $310 a 
month plus a one time fee of $140 [Ref. 25]. 
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ALTERNATIVE 5: REVIVE OLD HIS 



The FNOC HIS system was originally designed for use by 
one department head and later adopted for command-wide use. 
It was not designed with the organizations overall objec- 
tives in mind. It was designed to fill a particular need at 
that time. The designer of the program and those that had 
been directly involved in its operation, have long since 
departed FNOC. Documentation is not complete and therefore 
revision and/or updating will not be an easy task. It will 
take a great deal of time for someone to become familar 
enough with the code to start to adapt it. Additionally, 
there are still some very negative attitudes remaining con- 
cerning this MIS . It was never well defined, inputs and 
updates were erratic, and the system only received, sporadic 
attention by upper management. Not only did middle manag- 
ers, who were required to submit the update information, not 
derive any benefits from the system; but they saw that upper 
management was not utilizing it. They saw their efforts as 
wasted, and when they did see any outputs from the system it 
was not current information. 

This system required at least 1 full time administrator, 
although 2 would be more realistic considering the amount of 
data entry required. If the documentation were clear enough 
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and only minor changes were needed, this would clearly be 
an economical approach. The ramifications of the staff atti- 
tude problem is indeed difficult to predict. 

ALTERNATIVE 6: DEDICATED MINI 

Initially this alternative will be the most costly. Not 
only will the organization need to purchase the computer; 
they will also have to purchase or develop the software 
package. This alternative will, in all liklihood, take more 
time from decision to installation than the others. It will 
also require the involvement of more FNOC technical person- 
nel in the acquisition, due to the hardware. 

This alternative has several distinct advantages. Hav- 
ing a dedicated or semi-dedicated mini makes access easier 
and allows for continued operations when the main computer 
system goes down or is over loaded. It also allows the pos- 
sibility of a wider selection of software packages. Greater 
benefits may be derived by utilizing the mini for other man- 
agement and/or administrative applications, such as an 
inventory control system, electronic mail, etc. It also 
would open up a wider range of possible software packages 
for this and other applications. 
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IX. CONCLUSION AND RECOMMENDATIONS 



Project managers are responsible for planning and sche- 
duling various projects and assignments. They must face 
changing priorities and resources and respond appropriately. 
Changes and reevaluation of projects involving nev priori- 
ties, resource availability (or lack of availability ) , new 
dependencies, ect. make management of on going projects a 
full time job. 

A highly complex and expensive undertaking like a soft- 
ware development project requires careful planning. The 
project manager can not hope to schedule, measure, and con- 
trol' complex programming activity without a formalized, 
highly developed plan. All projects need planning. In most 
cases this involves a detailed breakdown of all the tasks 
which make up a project to ensure that realistic schedules 
of anticipated progress can be prepared. Bach task needs to 
be of an easily identifiable and self contained nature so 
that measurement of progress is made as simple as possible. 
Within each task self contained check points must be estab- 
lished so that comparison of actual progress against planned 
progress can be made at meaningful intervals. 
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The only realistic way to be in control is to see regu- 
lar evidence of progress (evidence of tasks/jobs completed) . 
Documents to control projects must take into account a 
balance between the need for control; and the desire to keep 
form 'filling to a minimum. 

One of the more important features of the project con- 
trol system is the method of reporting. It should serve to 
formalize the kind of casual reporting that occurs in all 
organizations. Formal reporting permits ready comparison of 
progress with plans and ensures a uniformity and consistency 
of information throughout the project. 

It is the author's opinion that FNOC needs a better 
defined and more uniform project information and control 
system. The current formal reporting mechanism and the 
informal reporting to the commanding officer, are neither 
adequate nor efficient. Verbal reports to the commanding 
officer are tine consuming and may not be the best presenta- 
tion node. Presentation of one project without a view of 
how it fits into the overall project environment may give a 
distorted picture. Use of the word processor for anything 
other than processing textual information is not authorized, 
therefore correlation of information must be accomplished in 
some other manner [Ref. 26 & 27]. 
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It is also the author* s opinion that correlation and 
presentation of project information can best be accomplished 
by an automated PICS. 

Based on information obtained in the preliminary analy- 
sis, the author’s preference is for the PAC II software 
package. This is based primarily on 2 findings. First, the 
fact that this system has been implemented successfully on 
CDC equipment and the same operating system as utilized at 
FNOC. Additionally, this package appears to be flexible 
enough to meet current and possible fututre needs of FNOC. 

Although it is the author’s opinion that adoption of an 
automated project information and control system at FNOC is 
a desirable action; and that this action if properly imple- 
mented will enhance FHOC’s effectiveness and efficiency; the 
following must serve to qualify this recommendation. 

The first and primary consideration for implementation 
is that top level management at FNOC must make the decision 
to give full and active support to such a system. Without 
this support the system has very little chance for success. 
Positive action must be taken if requirements are not met by 
principle investigators and project managers. A steering 
committee, whose primary function is to review procedures 
and assure compliance, might be considered. 
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Once the decision is made to provide this support, an 
evaluation group, composed of programmers, analysts, project 
managers and principle investigators, should be formed. The 
Executive Officer and/or the Commanding Officer may also 
wish to be a part of this group since they are also users. 
Acquisition must go out for competitve bid unless sole 
source can "be justified, which is unlikely in this case. 
Distributors of all packages reviewed offered demonstrations 
and/or presentaions of their package capabilities. It may 
be appropriate to allow vendors to make a presentation prior 
to the decision to automate. It would certainly serve to 
provide visual proof of what an automated system can and can 
not do. 

Once a package is selected; it is recommened that in 
order to minimize the disruption, FNOC not convert in-pro- 
cess projects to the new system. It would be best to start 
only new projects on the new system. This will minimize the 
burden on the staff and management personnel and allow for a 
smoother transition. 

The development and implementation of a project control 
system is, in itself a project. A great deal of extra 
effort is needed. Just how detailed any project control 
system becomes is a function of the system size and 
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complexity of the organization in which it is being applied. 
Generally, whatever the effort, the cost of a typical soft- 
ware development project is reason enough to justify it. 
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APPENDIX A 



Reguirenents Checklist 

gENEMi information 

This checklist is part of a study being conducted on pro- 
ject management and control at FNOC. The information on the 
following pages was acquired as a result of interviews con- 
ducted with a select group of key FNOC project personnel. 

The question posed was; what information requirements and/or 
capabilities would you like to see in a project management 
and control system at FNOC (either automated or manual) . 

The requirements listed on the following pages represent 
ONLY those that were mentioned during the personal inter- 
views. The list, in all probability, does not cover all pos- 
sible requirements. It is; however, a starting point. 

The requirements have been grouped according to six 
general functional categories to facilitate an orderly 
presentation mode. This categorization was based strictly on 
the subjective judgement of the interviewer. Some of the 
requirements could very well fit into more than one of the 
categories; however they are listed only once for 
simplicity. 



78 



DIRECTIONS 



Your cooperation is requested in reviewing and responding 
to the checlclist items on the following pages. Each item 
requires two checks; one in response to whether or not 
you*ll use the information and one in regards to how you 
would prefer it to be stored. 

If after reviewing these requirements you can add to the 
list please do so; your input will be a valuable addition. 
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